-
Notifications
You must be signed in to change notification settings - Fork 404
Add optional rapid sync timestamp field to NetworkGraph #1500
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add optional rapid sync timestamp field to NetworkGraph #1500
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1500 +/- ##
==========================================
+ Coverage 90.95% 92.17% +1.22%
==========================================
Files 80 80
Lines 42724 52517 +9793
Branches 42724 52517 +9793
==========================================
+ Hits 38858 48407 +9549
- Misses 3866 4110 +244
Continue to review full report at Codecov.
|
@@ -127,6 +127,7 @@ pub struct NetworkGraph { | |||
// Lock order: channels -> nodes | |||
channels: RwLock<BTreeMap<u64, ChannelInfo>>, | |||
nodes: RwLock<BTreeMap<NodeId, NodeInfo>>, | |||
last_rapid_gossip_sync_timestamp: Option<u32>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be pub
, documented, and updated automatically by the lightning-graph-sync
crate stuff, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes to 1) and 2), but 3) should be done in a separate PR, preferably the one with the background processor pruning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then maybe lets just do this in that PR? The docs need to talk about when its updated and how to use it, and that would imply changes to the lightning-rapid-sync
crate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lol I thought we wanted smaller, easy-to-read PRs :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with a clear separation of responsibilities :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean you're welcome to add documentation that describes how (3) will work, I guess, but its a bit confusing...whatever 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do!
Can you go ahead and squash? We should try to land this and the BP changes tomorrow and cut 107, there's not much left that isn't trivial. |
Yup! 🎃 |
It's technically a gourd, but the closest I could find to a squash emoji. |
fd75747
to
ffed82c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still kinda hate that this PR leaves the repo in an intermediate state where we have docs that are incorrect based on a as-yet-unimplemented PR, but I'm willing to live with it here given that's just the one thing we have to land for 107 anyway.
I hear you, but it's either that or massive PRs. |
In this case it really isn't, though - its one line on the gossip sync crate to update this field when we run an update. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we explain this change a little more in the commit message?
Other than that plus these nits, LGTM
…o enable optimized differental rapid syncing.
ffed82c
to
c3bbfe5
Compare
Updated commit message; lmk if I should rename the PR, too. @valentinewallace |
This field will be necessary for rapid gossip sync to not burden users with a one-off variable requiring separate storage.